Persistent dashboard for user interface

ABSTRACT

A method, user interface module, application program interface, computer program product and system that provides access to context information in a display window that remains persistent as the user navigates the application and views application data. The persistent dashboard can be populated from a communications event, such as an inbound telephone call; from data entered by the customer service agent via the user interface, such as a response to one of a series of scripted questions; from search results of a user-initiated search; or from application data displayed in a display window of the user interface. Various types of information from enterprise databases can be captured in the persistent dashboard to address the enterprise&#39;s business processes and needs. Information displayed in the persistent dashboard is configurable.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/185,180, entitled “Persistent Dashboard for User Interface”, filedJun. 27, 2002, and issuing on Nov. 16, 2010, as U.S. Pat. No. 7,836,403,naming Sabarivasan Viswanathan, Katherine H. Mobley, and Carl P. Kelleras inventors. This application is assigned to Siebel Systems, Inc., theassignee of the present invention, and is hereby incorporated byreference, in its entirety and for all purposes.

Portions of this patent application contain materials that are subjectto copyright protection. The copyright owner has no objection to thefacsimile reproduction by anyone of the patent document, or the patentdisclosure, as it appears in the Patent and Trademark Office file orrecords, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

User interfaces are becoming increasingly sophisticated by allowingaccess to numerous types of application data and/or application systems.For example, a typical customer service application may include a userinterface to allow a customer service agent to navigate among a varietyof types of data related to a customer. Such customer data may includecontact information, service request information, order information,activity information, and so on. A customer service agent interactingwith a customer may need to navigate quickly all of these types ofinformation during, for example, the course of a single telephoneconversation.

In order to provide personalized service, it is desirable that customerservice agents appear to “know” the customer immediately when startingan interaction and throughout its duration. Since customer servicecenters receive a large volume and variety of customer interactionsduring a typical day, each agent needs to have quick access to importantcustomer information, such as contact name, account number, phonenumber, and so on. However, even though changing application systemsand/or between types of application data may be possible using a singleuser interface, typically no context information is provided by the userinterface as the user navigates from one area to another. Often, thecustomer service agent writes down the customer's name, telephonenumber, or other important context information to remember while theagent navigates the customer's data. This work-around hinders agentproductivity and can lead to dissatisfactory customer interactions whensuch critical information is not available and the agent must ask thecustomer to repeat information.

What is needed is a customizable user interface that can providepersistent context information while a user navigates among differentscreens and views of the user interface and/or different types ofapplication data.

SUMMARY OF THE INVENTION

A persistent dashboard provides access to key context information in adisplay window that remains persistent as the user navigates theapplication and views application data. The persistent dashboard can bepopulated from a communications event, such as an inbound telephonecall; from data entered by the customer service agent via the userinterface, such as a response to one of a series of scripted questions;from search results of a user-initiated search; or from application datadisplayed in a display window of the user interface. For example, for aninbound telephone call, the persistent dashboard can be populatedimmediately with information regarding the caller, so that the agent hasinstant information about the caller even before he answers the call.Various types of information from enterprise databases can be capturedin the persistent dashboard to address the enterprise's businessprocesses and needs. Information displayed in the persistent dashboardis configurable.

In one feature, a method includes pushing context information fordisplay in a first display window of a user interface in response to afirst change in context and maintaining the context information fordisplay in the first display window until a second change in contextoccurs.

In another feature, a system includes means for pushing contextinformation for display in a first display window of a user interface inresponse to a first change in context and means for maintaining thecontext information for display in the first display window until asecond change in context occurs.

In an additional feature, a user interface module includes pushinginstructions to push context information for display in a first displaywindow of a user interface in response to a first change in context andmaintaining instructions to maintain the context information for displayin the first display window until a second change in context occurs.

In another feature, a computer program product includes pushinginstructions to push context information for display in a first displaywindow of a user interface in response to a first change in context andmaintaining instructions to maintain the context information for displayin the first display window until a second change in context occurs. Thecomputer program product further includes a computer-readable medium tostore the pushing instructions and the maintaining instructions.

In yet another feature, an application program interface includes acommand definition. The command definitions includes a pushing commandto push context information for display in a first display window of auser interface in response to a first change in context and amaintaining command to maintain the context information for display inthe first display window until a second change in context occurs.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the present invention, asdefined solely by the claims, will become apparent in the non-limitingdetailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings.

FIGS. 1A and 1B provide examples of a user interface including apersistent dashboard that operates according to the present invention.

FIG. 2 is a flowchart for updating the persistent dashboard in responseto changes in context.

FIG. 3 shows actions taken when updating the persistent dashboard inresponse to manipulation of application data by a user.

FIG. 4 shows actions taken when updating the persistent dashboard inresponse to an incoming communication event.

FIG. 5 shows actions taken when updating the persistent dashboard inresponse to an outgoing communication command.

FIG. 6 is a diagram of a layered architecture in which an embodiment ofthe persistent dashboard can be implemented.

FIG. 7 is a diagram of object layers and object definitions according tothe layered architecture of FIG. 6.

FIG. 8 is a block diagram illustrating a computer system suitable forimplementing embodiments of the present invention.

The use of the same reference symbols in different drawings indicatessimilar or identical items. While the invention is susceptible tovarious modifications and alternative forms, specific embodimentsthereof are shown by way of example in the Drawings and are describedherein in detail. It should be understood, however, that the Drawingsand Detailed Description are not intended to limit the invention to theparticular form disclosed. On the contrary, the intention is to coverall modifications, equivalents, and alternatives falling within thescope of the present invention as defined by the appended Claims.

DETAILED DESCRIPTION

For a thorough understanding of the subject invention, refer to thefollowing Detailed Description, including the appended Claims, inconnection with the above-described Drawings. Although the presentinvention is described in connection with several embodiments, theinvention is not intended to be limited to the specific forms set forthherein. On the contrary, it is intended to cover such alternatives,modifications, and equivalents as can be reasonably included within thescope of the invention as defined by the appended Claims.

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the invention. It will be apparent, however, to oneskilled in the art that the invention can be practiced without thesespecific details.

References in the specification to “one embodiment” or “an embodiment”mean that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments but not other embodiments.

Introduction

A persistent dashboard provides access to key context information in adisplay window that remains persistent as the user navigates theapplication and views application data. The persistent dashboard can bepopulated from a communications event, such as an inbound telephonecall; from data entered by the customer service agent via the userinterface, such as a response to one of a series of scripted questions;from search results of a user-initiated search; or from application datadisplayed in a display window of the user interface. For example, for aninbound telephone call, the persistent dashboard can be populatedimmediately with information regarding the caller, so that the agent hasinstant information about the caller even before he or she answers thecall. Various types of information from enterprise databases can becaptured in the persistent dashboard to address the enterprise'sbusiness processes and needs.

The persistent dashboard of the present invention can be configured todisplay information for various types of application data. The presentinvention is illustrated and described as part of a customer serviceapplication, although the invention is more broadly applicable and canbe used for any type of host application and user interface.

FIG. 1A shows a user interface 102A presented by a web browser client104A. In one embodiment, no client software other than a web browser,such as Microsoft Internet Explorer or Netscape Navigator, is needed torun the user interface for the host application. Web browser client 104Aalso includes functional control module 106A, which controls userinterface 102A. An example of a functional control module is a Javaapplet, which is downloaded when the user accesses the web page for thehost application having user interface 102A.

User interface 102A includes a communication toolbar 110A, screen tabs120A, a persistent dashboard 130A, and a base view 140A. Communicationtoolbar 110A and screen tables 120A are not essential for the operationof persistent dashboard 130A, but are included for purposes of showingthe usefulness of persistent dashboard 130A. Base view 140A represents adisplay window in which application data are displayed, such that thedashboard data provide context information related to the applicationdata, although base view 140A is not essential for operation ofpersistent dashboard 130A.

Communication toolbar 110A enables a user to communicate via multipletypes of communication channels, such as e-mail, telephone, facsimile,and wireless messaging. Screen tabs 120A enable a user to navigate amongvarious types of application data.

In the example shown, persistent dashboard 130A includes various datafields such as contact name 131A, company 132A, phone 133A, e-mail 134A,current computer 135A, interest 136A, and customer time 137A. Persistentdashboard 130A also includes customer history combo box 138A, whichenables the user to view the history of previous communications with thecustomer whose information is displayed in persistent dashboard 130A. Asmentioned above, the data fields included in a persistent dashboard,such as persistent dashboard 130A, are configurable according to thepresent invention. For example, an account number, customer's localtime, or other relevant context information can be selected to bedisplayed in persistent dashboard 130A. Furthermore, customer dashboard130A may be configured to include, for example, Previous and Nextbuttons (not shown) to enable scrolling to and from information relatedto previous activity of the agent using the host application, such ascalls that the agent had previously attended to during a session usingthe host application.

In the example embodiment shown, persistent dashboard 130A is visible asa separate frame below the communications toolbar 110A and screen tabs120A and above the frame including base view 140A. In base view 140A,the user can navigate among various types of application data and/ordifferent screens and view of user interface 102A, while persistentdashboard 130A provides a persistent view of context information relatedto the application data presented in base view 140A. For example, thecustomer service agent can quickly navigate to information related tothe active customer in persistent dashboard 130A by selecting from thecombo box 138A of persistent dashboard 130A. The list of views to whichthe agent can navigate is customizable and, for example, may include thefollowing:

Contact—Activities (default)

Contact—Activity Plans

Contact details

Contact—Service Requests

Contact—Agreements

Contact—Entitlements

Contact—Campaigns

Contact—Opportunities.

When a view is selected, one or more records related to the activecustomer are displayed in base view 140A.

FIG. 1B shows an alternative embodiment of the user interface shown inFIG. 1A, referred to as user interface 102B. User interface 102Bincludes components corresponding to the components described above withreference FIG. 1A, such as communication toolbar 110B, screen tabs 120B,persistent dashboard 130B, and base view 140B. Persistent dashboard 130Bcorresponds to persistent dashboard 130A of FIG. 1A, having equivalentdata fields 131B through 137B and customer history combo box 138B. Userinterface 102B also runs within corresponding web browser client 104Band has a corresponding functional control module 106B. Functionalcontrol module 106B controls user interface 102B.

In addition to the components shown in FIG. 1A, user interface 102Bincludes search center 150B, which enables the user to searchapplication data for a particular record of interest. In the exampleembodiment shown, persistent dashboard 130B is visible as a separateframe below the communications toolbar 110B and screen tabs 120B.Persistent dashboard 130B exists in addition to the frame includingsearch center 150B and the frame including base view 140B.

The following description uses user interface 102B and persistentdashboard 130B as examples of the general capabilities of a userinterface including a persistent dashboard according to the presentinvention.

Populating the Dashboard

The context information displayed in persistent dashboard 130B ischanged in response to certain actions, which are referred to herein aschanges in context. For example, a change in context can includereceiving a communication event, obtaining data entered by a user,focusing on a data record, and selecting a search results record.Actions such as switching to a new screen or view of the user interface,or viewing a different type of application data, are not considered totrigger changes in context unless accompanied by one of theaforementioned context-changing actions.

Once populated, the context information remains in persistent dashboard130B until another change in context occurs or until a Clear Dashboardcommand is executed. The context information remains available and isupdated for each change in context, even when the display windowincluding persistent dashboard 130B is closed. Dashboard data inpersistent dashboard 130B is updated so that, when the user re-opens adisplay window for persistent dashboard 130B, the context informationpertains to the currently active customer and application data.

Additionally, persistent dashboard 130B may be configured to include abutton in a display window to update dashboard data displayed withinformation related to application data also being displayed by userinterface 102B.

In one embodiment, user interface 102B is configured to include an OpenDashboard icon (not shown) and a Close Dashboard icon (not shown) thatcan be clicked to open and close persistent dashboard 130B. In thisembodiment, the commands Open Dashboard, Close Dashboard, and ClearDashboard can also be accessed from an application menu (not shown)using a View command.

Context Change: Receive Communications Event

In one embodiment, when an incoming communication arrives andnotification is provided to the agent by communications toolbar 110B,persistent dashboard 130B is automatically updated with key informationabout the caller, such as the contact name and customer's local time.While this information enables the agent to greet the customer using theproper salutation, the host application retrieves further informationabout the contact and displays customer-specific information. If thehost application finds more than one contact name having the sametelephone number, then no contact information is populated in persistentdashboard 130B. In this case, the user can find the appropriate contactinformation using Search Center 150B.

In one embodiment, during a live telephone call, the user may alsopopulate persistent dashboard 130B with contact information fromapplication data presented in views such as Contact, Service Request,Activity, or Campaign Contact using the keyboard shortcut,“Ctrl+Shift+P”. This command updates persistent dashboard 130B withcontext information, such as contact information, associated with theselected application data record. When releasing a telephone call,context information remains in persistent dashboard 130B until anotherchange in context occurs.

Context Change: Select Search Result Record

In one embodiment, the customer service agent can populate informationin persistent dashboard 130B from search center 150B. When the customercannot be automatically identified from the inbound call, the agent cansearch for the contact in search center 150B. To populate the dashboard,the user opens persistent dashboard 130B and clicks the “Set Dashboard”button in search center 150B.

Persistent dashboard 130B may be populated from any business object in aresults set from search center 150B, as long as the business object hasbeen configured for display in persistent dashboard 130B. Businesscomponent configuration is discussed further in detail below. If a userclicks the “Set Dashboard” button for a business object that has notbeen configured for display in persistent dashboard 130B, dashboard datadisplayed in persistent dashboard 130B is not updated.

Context Change: Obtain Data Entered by User

A context change can be initiated in response to data entered by theuser using a user interface, such as user interface 102B. For example,some host applications provide customer service agents with a scriptedseries of questions to ask of the customer, and the customer serviceagent enters a response to each question using the user interface of thehost application. Such a series of scripted questions is sometimesreferred to as a “SmartScript,” and the responses to questions arereferred to herein as SmartScript responses, or simply responses. As acustomer service agent enters responses, the responses may be updated topersistent dashboard 130B. SmartScript configuration is discussed infurther detail below. Other types of data entered may also trigger acontext change, and the invention is not limited to changing context forSmartScript responses.

Context Change: Focus on a Data Record

Once the persistent dashboard is populated with an application datarecord, such as a contact record, the customer service agent may quicklynavigate to information related to the active contact by selecting fromthe activity combo box 138B of persistent dashboard 130B. In oneembodiment, the host application is configured by default to allow theagent to navigate to the following views:

Contact—Activities (default)

Contact—Activity Plans

Contact details

Contact—Service Requests

Contact—Agreements

Contact—Entitlements

Contact—Campaigns

Contact—Opportunities.

The navigation takes the user to the appropriate view with focus on arecord related to the active contact. The views accessible frompersistent dashboard 130B quick navigation are also configurable, asdescribed below.

FIG. 2 is a flowchart for updating a persistent dashboard, such aspersistent dashboard 130B, in response to changes in context. At ContextChange decision point 210, a determination is made whether or not acontext change has been made in user interface 102B. If no contextchange has occurred, no transition is made from Context Change decisionpoint 210. If a context change has occurred, control transitions toCommunication Event decision point 220 to test whether a communicationevent has been received. If a communication event has been received,control transitions to Update Dashboard Data with Context Informationfor Communication Event step 222. Dashboard data are updated withcontext information, such as the name of the customer initiating thecommunication event. For example, if the communication event is anincoming telephone call, the name of the customer is instantaneouslydisplayed in persistent dashboard 130B as the telephone is ringing.

Control then transitions to Dashboard Window Open decision point 270,where a determination whether a display window for persistent dashboard130B is open is made. If persistent dashboard 130B is open, controltransitions to Display Updated Dashboard Data step 280. Contextinformation related to the communication event is displayed in theupdated dashboard.

If in Dashboard Window Open decision point 270, persistent dashboard130B window is not open, updated dashboard data will be available withthe updated context information for the communication event when adisplay window for persistent dashboard 130B is open. Control thentransitions back to Context Change decision point 210.

If at Communication Event decision point 220, the context change is nota communication event, control transitions to Data Entered decisionpoint 230. In Data Entered decision point 230, a determination is madewhether or not data have been entered. For example, a response may beobtained when the customer service agent uses a scripted list ofquestions (“SmartScript”) that the customer service agent reads to thecustomer. When a response to one of the questions is obtained andentered by the customer service agent, entry of the responseautomatically triggers a change in context.

When data are entered by the user, control transitions to UpdateDashboard Data with Context Information for Data Entered step 232.Dashboard data related to the response is updated and controltransitions to Dashboard Window Open decision point 270.

If at Data Entered decision point 230, no data have been entered,control transitions to Focus on Data Record decision point 240. If atFocus on Data Record decision point 240, the user has focused on a datarecord, control transitions to Update Dashboard Data with ContextInformation for Data Record step 242. Dashboard data in persistentdashboard 130B related to the focus data record is updated, and controltransitions to Dashboard Window Open decision point 270.

If at Focus on Data Record decision point 240, no data record is infocus, control transitions to Search Results Record Selected decisionpoint 250. A determination is made whether a search result record hasbeen selected by the user, and if so, control transitions to UpdateDashboard Data with Context Information for Selected Record step 252.Context information for the selected record, such as a customer namerelated to the selected record, is updated, and control transitions toDashboard Window Open decision point 270.

If at Search Result Record Selected decision point 250, no search resultrecord is selected, control transitions to No Update step 260. No updateis made to dashboard data, and control transitions to Dashboard WindowOpen decision point 270.

As noted above, if in Dashboard Window Open decision point 270, adisplay window for persistent dashboard 130B is not open, updateddashboard data will be available with the updated context informationfor the communication event when a display window for persistentdashboard 130B is opened. Control then transitions back to ContextChange decision point 210.

While four types of context changes are shown in FIG. 2, one of ordinaryskill will recognize that other types of context changes may be used totrigger an update of a persistent dashboard, such as persistentdashboard 130B. The present invention enables an administrator to definecustomized events for his or her enterprise that can also be used totrigger an update of dashboard data. The scope of the invention includesthese other types of context changes and is not limited to those shownin FIG. 2.

FIG. 3 shows actions taken when updating a persistent dashboard inresponse to a user-generated user interface event, such as focusing on adata record, selecting a data record from a search result, or enteringdata. When a user-generated user interface event occurs, a change incontext is initiated, which in turn updates persistent dashboard 130B.In action 3.1, the agent initiates a change in context by, for example,selecting a data record from a search result. In action 3.2, functionalcontrol module 106B passes a request to access data to web server 330.In action 3.3, web server 330 passes the request to access applicationdata to application server 340. Application server 340 can include apersistent dashboard business service (not shown) to assist withobtaining data to push to persistent dashboard 130B. As noted by thebroken arrow connecting web server 330 to application server 340,intermediate software modules may be present between web server 330 andapplication server 340.

Application server 340 accesses application data 350 in action 3.4. Asnoted by the broken arrow connecting application server 340 toapplication data 350, several intermediate modules may be present, suchas a database server (not shown). Application server 340 providesapplication data to web server 330 in action 3.5, and web server 330provides application data to web browser client 104B in action 3.6. Inaction 3.7, functional control module 106B updates context informationrelated to the application data shown in persistent dashboard 130B. Inaction 3.8, functional control module 106B updates application datadisplayed by basic view 140B of user interface 102B.

FIG. 4 shows actions taken when updating the persistent dashboard inresponse to an incoming communication event, such as an incomingtelephone call or e-mail. In action 4.1, the customer places a requestfor customer support using media device 420. The request for customersupport is provided via a series of intermediate software modules (notshown) to communication server 410. Communication server 410 receivesthe event and provides an event response in action 4.3 to web server330. Again, as indicated by the broken arrow connecting communicationserver 410 and web server 330, intermediate software modules may existbetween communication server 410 and web server 330. Web server 330provides the event response to web browser client 104B, and functionalcontrol module 106B updates persistent dashboard 130B with contextinformation related to the incoming communication event. This contextinformation may include, for example, the name of the customerinitiating the telephone call. In action 4.6, functional control module106B provides notification of the incoming communication event tocommunication toolbar 110B. Communication toolbar 110B then providesnotification of the communication event to the customer service agent,for example, by causing a button on communication toolbar 110B to blink.

FIG. 5 shows updates to user interface 102B when a customer serviceagent issues a communication command, for example, by clicking on abutton of communication toolbar 110B to initiate a telephone call.Issuing a communication command is similar to the user-generated userinterface events described with reference to FIG. 3, although othersoftware modules, such as communication server 410 of FIG. 4, areinvolved. In action 5.1, the customer service agent clicks a Make Callbutton on communication toolbar 110B to initiate a telephone call. Theresulting communication command produces a change in context that isused to update persistent dashboard 130B. Updating persistent dashboard130B may involve additional modules not shown, such as applicationserver 340 of FIG. 3, to access application data related to thecommunication command. In action 5.2, functional control module 106Bdetermines the communication command to be issued. In action 5.3,functional control module 106B updates persistent dashboard 130B withcontext information related to the communication command. In action 5.4,functional control module 106B provides the command to be issued to webserver 330. Web server 330 provides the command to communication server410. Communication server 410 then issues the command in action 5.6, viaseveral intermediate software modules (not shown), to media device 420.

Example Architecture

FIG. 6 is a diagram of a layered architecture in which an embodiment ofthe persistent dashboard can be implemented. Application architecture602 includes user interface objects layer 610, business objects layer620, and data objects layer 630. User interface objects layer 610includes one or more user interface object definitions 612. An exampleof a user interface object definition is a view definition for base view140B. Business objects layer 620 includes one or more business objectdefinitions 622. An example of a business object definition is a contactbusiness object definition. Data objects layer 630 includes one or moredata object definitions 632. An example of a data object definition is aschema for a database table. Underlying database architecture 604, whichis used to store application data, includes a database management system(DBMS) 640.

FIG. 7 is a diagram of object layers and object definitions according tothe layered architecture of FIG. 6. User interface objects layer 610includes object definitions application 711, screen 713, view 715,applet 717, and control 719. As used herein, an application objectdefinition defines a collection of screens and does not define anapplication program. Application object definition 711 includes one ormore screen 713. Each screen 713 may contain one or more view 715. Aview presents one or more applets together at one time in a pre-definedvisual arrangement and logical data relationship. Each view 715 maycontain one or more applet 717. In the architecture of the presentinvention, the term applet is used to describe a form including one ormore fields and controls, and is distinguishable from the term appletwhen used to describe, for example, a Java program referred to as a Javaapplet. Each applet 717 may include one or more control 719.

Business objects layer 620 includes business object definition 722,business component definition 724, and field object definition 726. Eachbusiness object definition 722 can include one or more businesscomponent object definition 724. Each business component objectdefinition 724 may include one or more field object definition 726.

Data object layer 630 includes table object definition 732 and columnobject definition 734. Each table object definition 732 can include oneor more column object definition 734.

As shown in FIG. 7, view object definition 715 of user interface objectlayer 610 maps to business object definition 722 of business objectslayer 620. A mapping indicates a one-to-one relationship between objectsdefined according to the object definitions. For example, a contact viewof user interface 102B displays data for a contact business object.

As noted above, a view may include one or more applets, and a businessobject may include one or more business components. Accordingly, appletsobject definition 717 of user interface object layer 610 maps tobusiness component object definition 724 of business objects layer 620.A particular applet, or form, of user interface 102B includes data for aparticular business component. Furthermore, a business component, suchas business component 724, maps to an object definition, such as tableobject definition 732, of data objects layer 630. Consequently, aparticular applet displays data for a particular business component froma particular data table. In at least one embodiment, a “virtual”business component corresponds to a business component for which dataare not obtained from a single database table, but instead are theresult of a combination of joins with two or more database tables.

Control object definition 719 of user interface object layer 610 maps tofield object definition 726 of business objects layer 620. A particularcontrol within an applet corresponds to a field object definition.Furthermore, field object definition 726 maps to column objectdefinition 734 of data object layer 630. Data for a column of aparticular table corresponds to a field of the corresponding businesscomponent and is displayed within a control in a corresponding applet.

A persistent dashboard, such as persistent dashboard 130B, can beimplemented as a separate frame and view below communication toolbar110B and above base view 140B. Persistent dashboard 130B is based on avirtual business component called “Persistent dashboard” which lies inthe instance of a “Persistent dashboard” business object. Examples ofobject definitions related to a persistent dashboard, such as persistentdashboard 130B, are given below:

Persistent Dashboard Business Object

Persistent Dashboard Business Component (virtual business component)

Persistent Dashboard Business Service (controls the functionality—alsoreferred to as “persistent engine”)

Persistent Dashboard Applet (user interface)

Persistent Dashboard View (user interface)

When updating persistent dashboard 130B from communication toolbar 110B,a SmartScript response, or search center 150B, an application programcan use an UpdateDashboard application program interface (API) for thePersistent Dashboard Business Service. The UpdateDashboard API can becalled using the InvokeMethod function of the Persistent DashboardBusiness Service and passing a set of name/value pairs, such as thefollowing:

Source Name: ‘Base View’

BusComp Name: ‘Contact’

RowId: ‘srowid’

In one embodiment, the InvokeMethod function of the Persistent DashboardBusiness Service is used to call UpdateDashboard API for configurableevents. For example, an enterprise may define a customized event forwhich the dashboard is updated and associate the customized event with abutton on an applet within the user interface.

Upon receiving the arguments, the invoked function of the PersistentDashboard Business Service obtains the set of fields configured to bedisplayed, retrieves corresponding data from application databases, andpopulates persistent dashboard 130B. The UpdateDashboard API andPersistent Dashboard Business Service are discussed in further detailbelow.

Dashboard Configuration

In one embodiment, persistent dashboard 130B is configurable. Forexample, various user interface changes can be made, such as changingthe color, size, location, and adding or removing fields from thedisplay window (applet) displaying persistent dashboard 130B.

In one embodiment, a list of views can be configured to which an agentcan quickly navigate using activity combo box 138B of persistentdashboard 130B. In one embodiment, the administrator can specify thelist of views at design time using user properties of the PersistentDashboard Business Service. A user property is an attribute of anobject, such as a user interface control, that can be used to definespecialized properties that define the object's run-time behavior. Theseuser properties enable the text box to behave differently than otherobjects that are instances of the object's class. For example, for atext box user interface object, a user property with value ‘[0-9]’ canbe defined so that the text box accepts only numeric input, such as azip code. Such a user property enables the text box to reject alphabeticcharacters at run-time as invalid values, in contrast to the behaviorfor most text boxes.

The list of views is specified with user properties named “View 1”,“View 2” and so on. A standard set of views is displayed. In oneembodiment, user properties “View 1” through “View 8” are created andshipped with the host application.

In one embodiment, the Persistent Dashboard Business Component obtainsthe list of user properties that have names with a “View” prefix atrun-time, finds the display name for the views, and adds the view namesto the activity combo box 138B list of values. If the name of aparticular view is specified incorrectly, that view is not listed. Inone embodiment, there is no limit to the number of views that theadministrator can specify.

In one embodiment, another configurable feature is the list of businesscomponent fields that appear on persistent dashboard 130B. In oneembodiment, a set of labels and edit boxes are pre-configured onpersistent dashboard 130B for a set of default fields. The administratorcan set a list of user properties, one for each business component, eachhaving names beginning with “List,” such as “List 1”, “List 2”, and soon. The name of a particular business component is specified first, andthe fields from that business component are specified one after theother, separated by the field separator “;”.

For example, if the Last Name and First Name fields from a Contactbusiness component and the type field from an Activity businesscomponent are to be displayed on persistent dashboard 130B, theadministrator creates user properties with the following attributes:

Name: List 1 Value: “Contact;Last Name;First Name”

Name: List 2 Value: “Activity;Type”

In one embodiment, several different types of fields can be placed onpersistent dashboard 130B, such as business component fields, data entryfields, and communication toolbar 110B data-driven fields.

As mentioned earlier, some edit boxes can be pre-created on persistentdashboard 130 B for display purposes. These edit boxes can have namessuch as “Field 1”, “Field 2” and so on. If Field 1 is always used todisplay the Contact Last Name, a new user property can be created asfollows:

Name: Field 1 Value: “List 1.1”

where the string “List 1.1” refers to the first field name of the userproperty with name “List 1”.

To display in Field 2 the activity type and the Service RequestAbstract, a new user property can be created as follows:

Name: Field 2 Value: “List 2.1;List 3.1”

The list of fields, such as SmartScript response fields, that are passedas name/value pairs can be specified as a user property with a name suchas “SmartScript List”.

To create a list of communication toolbar 110B data-driven fields, theadministrator can create a user property with a name such as“Communication List.” For example, to display the number of calls inqueue (which is a communication toolbar 110B data-driven field), theLast and First Names from the Contact business component, the type ofthe activity, and an abstract of the service request, the administratorcan create four user properties as follows:

Name: Communication List Value:“Calls in queue”

Name: List 1 Value: “Contact;Last Name;First Name”

Name: List 2 Value: “Activity;Type”

Name: List 3 Value: “Service Request;Abstract”

The above examples show how an administrator can configure each field onpersistent dashboard 130B.

When context information is pushed to persistent dashboard 130B (fromcommunication toolbar 110B or search center 150B), persistent dashboard130B code goes through the list of user properties starting with, forexample, “Field,” searches for the fields mapped to the relevantbusiness component, such as the Contact business component, and updatesthese fields on persistent dashboard 130B.

Fields that are not mapped in user properties are not updated inpersistent dashboard 130B. If the business component name or field namespecified by the administrator in user properties is not valid, thefield will not be mapped. In contrast to the user properties for thelist of quick navigation views, which has no limit, the maximum numberof fields is limited by the number of fields available on persistentdashboard

Each field and the corresponding field label of persistent dashboard130B can be configured by an administrator. To save space, the samelabel can be used for fields from different tables; for example, thelabel “Name” can be used for both an Account Name and a Contact Name.Alternatively, each field can be configured with its own label tocorrespond to the data being displayed.

Persistent Engine

A persistent engine within the host application server is responsiblefor ensuring that persistent dashboard, such as persistent dashboard130B, is continually updated whenever a change in context occurs. In oneembodiment, the persistent engine is implemented as a persistentdashboard business service. The persistent dashboard business serviceprovides an application program interface (API) that includes a memberfunction to update persistent dashboard 130B from communication toolbar110B. In one embodiment, the member function is called UpdatefromCTI,which updates persistent dashboard 130B whenever a communication eventoccurs. Member functions can correspond to a command definition for acommand to, for example, push context information for display in a firstdisplay window of a user interface in response to a first change incontext. The Update Dashboard API may further include a commanddefinition for a maintain command to maintain the context informationfor display in the first display window until a second change in contextoccurs.

The communication administration views can be pre-configured to callInvokeMethod (with UpdateDashboard as a parameter) when a communicationevent is received. Variables such as Phone number, Number of calls inqueue, and other communication-related variables are passed as argumentsto update persistent dashboard 130B. When InvokeMethod is called withthe UpdateDashboard parameter, the business service member functionUpdatefromCTI obtains the list of fields that are configured to bedisplayed in persistent dashboard 130B. Data to update persistentdashboard 130B can be passed as parameters and/or queried fromappropriate application databases using key information, such as ContactID, for the telephone number associated with the incoming telephonecall.

Other modules, such as a SmartScript or Search Center 150B, notifypersistent dashboard 130B when relevant information needs to be updated.These modules use the same API described above, UpdateDashboard. TheUpdateDashboard API is called from different modules (through theInvokeMethod function of the Persistent Dashboard Business Service), andthe arguments passed are a set of name/value pairs representingpersistent dashboard 130B fields. Upon receiving the arguments, themember function(s) of the Persistent Dashboard Business Service obtainthe set of fields configured to be displayed and populate persistentdashboard 130B directly or after retrieving the data from an applicationdatabase.

For example, in one embodiment, the UpdateDashboard API can be calledfrom Search Center 150B when a member of the Search Center search resultset is a contact record and a “Set Dashboard” control is selected. If acustomer service agent is talking to a customer and persistent dashboard130B is populated with the customer's information, when the “SetDashboard” button is clicked, data in persistent dashboard 130B will bereplaced with new information from the search results. The informationabout the customer who is currently talking with the customer serviceagent is overwritten. In some embodiments, past versions of dashboarddata can be retrieved.

The UpdateDashboard API can be called by a SmartScript module wheneverrelevant information is provided (where relevance is determined by theSmartScript module itself). In one embodiment, persistent dashboard 130Bdoes not determine which fields are updated with data entered by theuser, such as a SmartScript response, and the determination of relevancefor a SmartScript response (as well as for other types of data entered)is configurable.

By providing this interface API that can be called from various modulesin the host application or from other applications, persistent dashboard130B does not need other data about the architecture of other modules.

Since the persistent dashboard is implemented as a business service, aprogram calling persistent dashboard 130B may use a GetService(“Persistent dashboard”) command. The program may set up a control toeither push information to persistent dashboard 130B or pull informationfrom persistent dashboard 130B. Details for example commands provided bythe Persistent Dashboard Business Service are displayed in Table 1below.

TABLE 1 Command Description GetCurrentRecordId This command returns therecord ID for the current record populated in the dashboard. Forexample, if the record is from the Contact business component, a ContactId is returned. If the record is from the Account business component, anAccount Id is returned. GetDashboardFieldValue This command returns thecurrent field value for the record populated in the dashboard. The inputargument is the name/value pair for the dashboard field. The outputargument is a field value. Update Dashboard This command is used topopulate the dashboard with a new record. For example, the followingparameters can be used for a field to update the dashboard from aContact Name displayed in base view 140B: Source Name: Base View BuscompName: Contact RowId: E301

System Suitable for Implementing the Present Invention

FIG. 8 depicts a block diagram of a computer system 10 suitable forimplementing the present invention. Computer system 10 includes a bus 12which interconnects major subsystems of computer system 10 such as acentral processor 14, a system memory 16 (typically RAM, but which mayalso include ROM, flash RAM, or the like), an input/output controller18, an external audio device such as a speaker system 20 via an audiooutput interface 22, an external device such as a display screen 24 viadisplay adapter 26, serial ports 28 and 30, a keyboard 32 (interfacedwith a keyboard controller 33), a storage interface 34, a floppy diskdrive 36 operative to receive a floppy disk 38, and a CD-ROM drive 40operative to receive a CD-ROM 42. Also included are a mouse 46 (or otherpoint-and-click device, coupled to bus 12 via serial port 28), a modem47 (coupled to bus 12 via serial port 30) and a network interface 48(coupled directly to bus 12).

Bus 12 allows data communication between central processor 14 and systemmemory 16, which may include both read only memory (ROM) or flash memory(neither shown), and random access memory (RAM) (not shown), aspreviously noted. The RAM is generally the main memory into which theoperating system and application programs are loaded and typicallyaffords at least 16 megabytes of memory space. The ROM or flash memorymay contain, among other code, the Basic Input-Output system (BIOS)which controls basic hardware operation such as the interaction withperipheral components. Applications resident with computer system 10 aregenerally stored on and accessed via a computer readable medium, such asa hard disk drive (e.g., fixed disk 44), an optical drive (e.g., CD-ROMdrive 40), floppy disk unit 36 or other storage medium. Additionally,applications may be in the form of electronic signals modulated inaccordance with the application and data communication technology whenaccessed via network modem 47 or interface 48.

Storage interface 34, as with the other storage interfaces of computersystem 10, may connect to a standard computer readable medium forstorage and/or retrieval of information, such as a fixed disk drive 44.Fixed disk drive 44 may be a part of computer system 10 or may beseparate and accessed through other interface systems. Many otherdevices can be connected such as a mouse 46 connected to bus 12 viaserial port 28, a modem 47 connected to bus 12 via serial port 30 and anetwork interface 48 connected directly to bus 12. Modem 47 may providea direct connection to a remote server via a telephone link or to theInternet via an internet service provider (ISP). Network interface 48may provide a direct connection to a remote server via a direct networklink to the Internet via a POP (point of presence). Network interface 48may provide such connection using wireless techniques, including digitalcellular telephone connection, Cellular Digital Packet Data (CDPD)connection, digital satellite data connection or the like.

Many other devices or subsystems (not shown) may be connected in asimilar manner (e.g., bar code readers, document scanners, digitalcameras and so on). Conversely, it is not necessary for all of thedevices shown in FIG. 8 to be present to practice the present invention.The devices and subsystems may be interconnected in different ways fromthat shown in FIG. 8. The operation of a computer system such as thatshown in FIG. 8 is readily known in the art and is not discussed indetail in this application. Code to implement the present invention maybe stored in computer-readable storage media such as one or more ofsystem memory 16, fixed disk 44, CD-ROM 42, or floppy disk 38.Additionally, computer system 10 may be any kind of computing device,and so includes personal data assistants (PDAs), network appliances,X-window terminals or other such computing devices. The operating systemprovided on computer system 10 may be MS-DOS®, MS-WINDOWS®, OS/2®,UNIX®, Linux® or other known operating system. Computer system 10 alsosupports a number of Internet access tools, including, for example, anHTTP-compliant web browser having a JavaScript interpreter, such asNetscape Navigator® 3.0, Microsoft Explorer® 3.0 and the like.

Moreover, regarding the messages and/or data signals described herein,those skilled in the art will recognize that a signal may be directlytransmitted from a first block to a second block, or a signal may bemodified (e.g., amplified, attenuated, delayed, latched, buffered,inverted, filtered or otherwise modified) between the blocks. Althoughthe signals of the above described embodiment are characterized astransmitted from one block to the next, other embodiments of the presentinvention may include modified signals in place of such directlytransmitted signals as long as the informational and/or functionalaspect of the signal is transmitted between blocks. To some extent, asignal input at a second block may be conceptualized as a second signalderived from a first signal output from a first block due to physicallimitations of the circuitry involved (e.g., there will inevitably besome attenuation and delay). Therefore, as used herein, a second signalderived from a first signal includes the first signal or anymodifications to the first signal, whether due to circuit limitations ordue to passage through other circuit elements which do not change theinformational and/or final functional aspect of the first signal.

Other Embodiments

The present invention is well adapted to attain the advantages mentionedas well as others inherent therein. While the present invention has beendepicted, described, and is defined by reference to particularembodiments of the invention, such references do not imply a limitationon the invention, and no such limitation is to be inferred. Theinvention is capable of considerable modification, alteration, andequivalents in form and function, as will occur to those ordinarilyskilled in the pertinent arts. The depicted and described embodimentsare examples only, and are not exhaustive of the scope of the invention.

The foregoing described embodiments include components contained withinother components. It is to be understood that such architectures aremerely examples, and that in fact many other architectures can beimplemented which achieve the same functionality. In an abstract butstill definite sense, any arrangement of components to achieve the samefunctionality is effectively “associated” such that the desiredfunctionality is achieved. Hence, any two components herein combined toachieve a particular functionality can be seen as “associated with” eachother such that the desired functionality is achieved, irrespective ofarchitectures or intermediate components Likewise, any two components soassociated can also be viewed as being “operably connected,” or“operably coupled,” to each other to achieve the desired functionality.

The foregoing detailed description has set forth various embodiments ofthe present invention via the use of block diagrams, flowcharts, andexamples. It will be understood by those within the art that each blockdiagram component, flowchart step, operation and/or componentillustrated by the use of examples can be implemented, individuallyand/or collectively, by a wide range of hardware, software, firmware, orany combination thereof.

The present invention has been described in the context of fullyfunctional computer systems; however, those skilled in the art willappreciate that the present invention is capable of being distributed asa program product in a variety of forms, and that the present inventionapplies equally regardless of the particular type of signal bearingmedia used to actually carry out the distribution. Examples of signalbearing media include recordable media such as floppy disks and CD-ROM,transmission type media such as digital and analog communications links,as well as media storage and distribution systems developed in thefuture.

The above-discussed embodiments may be implemented by software modulesthat perform certain tasks. The software modules discussed herein mayinclude script, batch, or other executable files. The software modulesmay be stored on a machine-readable or computer-readable storage mediumsuch as a disk drive. Storage devices used for storing software modulesin accordance with an embodiment of the invention may be magnetic floppydisks, hard disks, or optical discs such as CD-ROMs or CD-Rs, forexample. A storage device used for storing firmware or hardware modulesin accordance with an embodiment of the invention may also include asemiconductor-based memory, which may be permanently, removably orremotely coupled to a microprocessor/memory system. Thus, the modulesmay be stored within a computer system memory to configure the computersystem to perform the functions of the module. Other new and varioustypes of computer-readable storage media may be used to store themodules discussed herein.

The above description is intended to be illustrative of the inventionand should not be taken to be limiting. Other embodiments within thescope of the present invention are possible. Those skilled in the artwill readily implement the steps necessary to provide the structures andthe methods disclosed herein, and will understand that the processparameters and sequence of steps are given by way of example only andcan be varied to achieve the desired structure as well as modificationsthat are within the scope of the invention. Variations and modificationsof the embodiments disclosed herein can be made based on the descriptionset forth herein, without departing from the scope of the invention.

Consequently, the invention is intended to be limited only by the scopeof the appended claims, giving full cognizance to equivalents in allrespects.

1. A method comprising: pushing context information for display in afirst display window of a user interface in response to a first changein context; and maintaining the context information for display in thefirst display window until a second change in context occurs.